This "fixes" several hundreds of typing errors and warnings. Leaving us with several hundred of relevant warnings and about fifty relevant and potentially problematic errors.

I assume you are type checking locally? I don't see the tool you are using or any readme information on how you would use these stubs. Do you also want to add 'mypy' or 'ty' to the requirements to make it complete?

I assume you are type checking locally? I don't see the tool you are using or any readme information on how you would use these stubs. Do you also want to add 'mypy' or 'ty' to the requirements to make it complete?

The reasoning for adding this was:

Yes. My nvim, as well as vscode and zed will run typecheckers on python by default. But: This PR is not to introduce typing. Nor to fix actual potential bugs found by typing.

Obv. I can disable my editor(s) from typechecking on certain projects/branches etc, but I find it highly beneficial to:

• Ensure new code is properly type hinted
• refactor-on-touch: when updating classes or functions, at least ensure the parts around where stuff is changed, is also typed
• new code, changes or refactors don't introduce new typing issues.

I personally prefer basedpyright (long story); but any one is good enough.
Until the project requires a typechecker - and enforces it in CI etc etc - it can be really useful for individual developers to have to option to use type hinting and type checking when developing.

Without these stubs, typing is unusable, so we lack the option to use the IDEs typechecking, type-hinting, etc. But also, inline documentation, smart, scoped, auto-complete, "goto definition", "rename symbol" and so on (aka LSP, aka intellisense), are not avaiable in the editor, or are rather unusable on anything "Django" (models, etc)

Also, without the stubs, literally hundreds of warnings and errors that are not a problem spam the project. Hiding actual problems. This goes for any code, also new files or new classes that use Django features like models.